src/core/__tests__/client.query/customScalars.test.ts (1)

568-639: 🎯 Functional Correctness | 🔵 Trivial

Unresolved TODO baked into assertion.

The test asserts startDate is parsed inside CombinedGraphQLErrors.data with a // TODO: Determine if this is correct comment. This pattern (serialized in none/ignore policies vs. parsed here) repeats identically across client.mutate, client.subscribe, and createQueryPreloader tests. Worth resolving whether error.data should stay serialized (matching the none policy test) or intentionally diverge for all.

Want me to open a tracking issue for this?

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/core/__tests__/client.query/customScalars.test.ts` around lines 568 -
639, The test in customScalars.test.ts contains an unresolved TODO inside the
CombinedGraphQLErrors.data assertion for client.query with errorPolicy "all".
Remove the TODO and make the expectation consistent with the intended behavior
for scalar handling in error data: either assert the serialized value to match
the "none"/"ignore" cases, or keep the parsed Date only if that is the
deliberate contract for errorPolicy "all". Apply the same decision consistently
across the related client.mutate, client.subscribe, and createQueryPreloader
tests so the behavior is uniform.

src/core/QueryInfo.ts (1)

329-337: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Correct fix, matches diff.result nullability contract.

The broadened condition correctly writes back the in-flight incremental diff so parsed scalars propagate to intermediate @defer chunks. Since diff.result is typed as DeepPartial<T> | null (never undefined) when !diff.complete, the !== null check is safe.

One minor nit: this.incremental?.hasNext duplicates the existing hasNext getter (Line 182-184) which already encapsulates this exact check. Using this.hasNext here would be slightly more consistent with usage elsewhere in the file (e.g., Lines 405, 513, 526).

♻️ Optional consistency tweak

           if (
             diff.complete ||
             // Use the diff result if the query is still an in-flight
             // incremental query so that parsed custom scalar values
             // in diff.result are returned.
-            (this.incremental?.hasNext && diff.result !== null)
+            (this.hasNext && diff.result !== null)
           ) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/core/QueryInfo.ts` around lines 329 - 337, The incremental diff
write-back in QueryInfo should use the existing hasNext getter instead of
duplicating its logic with this.incremental?.hasNext. Update the condition in
the result merge block so it checks this.hasNext together with diff.result !==
null, keeping the current nullability-safe behavior while matching the rest of
QueryInfo’s usage and reducing duplicated state checks.

src/core/__tests__/client.watchQuery/customScalars.test.ts (1)

1105-1193: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Unresolved TODO questions correctness of an assertion.

// TODO: Determine if this is correct (line 1173-1174) flags uncertainty about whether the parsed startDate should appear inside CombinedGraphQLErrors.data for errorPolicy: "all". This same TODO is duplicated across several other new test files in this PR (useQuery, useLazyQuery, useMutation, useBackgroundQuery, useSuspenseQuery, useLoadableQuery). Worth resolving before merge since it signals the author isn't fully confident in the asserted behavior.

Want me to help investigate the expected error-data shape for errorPolicy: "all" and propose a fix/clarifying comment?

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/core/__tests__/client.watchQuery/customScalars.test.ts` around lines 1105
- 1193, The test assertion in ObservableStream for `client.watchQuery` has an
unresolved TODO about the shape of `CombinedGraphQLErrors.data` under
`errorPolicy: "all"`. Confirm the expected error payload for parsed scalars in
the `watchQuery` path and then either keep the parsed `startDate` in the
asserted error data or adjust the assertion to match the actual behavior,
removing the TODO; also apply the same fix pattern to the matching new tests in
the other query/mutation hooks if they share this uncertainty.

src/react/hooks/__tests__/useLoadableQuery/customScalars.test.tsx (1)

541-558: 🩺 Stability & Availability | 🔵 Trivial

Resolve the TODO on error-data scalar serialization before un-drafting.

Under errorPolicy: "all" the CombinedGraphQLErrors data expects startDate as a parsed Date, whereas the errorPolicy: "none" test (Line 443) expects the raw string "2026-01-01" for the same field. This asymmetry is exactly what the // TODO: Determine if this is correct comment questions and should be pinned down so the test encodes intended behavior rather than incidental behavior.

Want me to open an issue to track deciding whether error-embedded scalars should be parsed or left serialized?

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/react/hooks/__tests__/useLoadableQuery/customScalars.test.tsx` around
lines 541 - 558, Resolve the TODO in the error-policy test by establishing the
intended scalar representation for error-embedded data and making the
`errorPolicy: "all"` and `errorPolicy: "none"` assertions consistent. Update the
test data and expectations around `CombinedGraphQLErrors` and the corresponding
`startDate` case so the chosen parsed-`Date` or raw-string behavior is
explicitly pinned down.